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Data processing with native and interpreted ijrosrain instruction words 

(57) An interpreter invocation meolianism for 8v\ritching between execution of native instruction words (ARIM, 
Tliumb) and interpreted Instruction words (Photon) uses a subroutine cail instruction (14) to start execution of 
the interpreter. The return address of the subroutine eali instruction (14) is used as an address pointer to the 
start of the interpreted code (16). Tlia interpreted code may terminate with an Exit instruction whereupon 
normal native code execution resumes using the instruction at the Immediately following memory address or 
altematlvaiy with e Return Instruction that recovers a return address previously stored to stack memory. 
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DATA PROCESSING WITH NATIVE AND INTERPRETED 
PROGRAM INSTI^U<;T?QN WQRPS 

Tias invention relates to the field of data processing systems. More 
5 particularly, this invention relates to data processing system operating under control 
of a mix of native and interpreted program instruction words. 

Computer programs or subroutines written in the form of interpreted program 
instructions words are typically smaller in size than the same computer programs or 
sxjbroutines written in the form of native programs instruction words. High code 
10 density is desirable as it reduces system memory requirements. However, computer 
programs or subroutines written in the form of interpreted program instruction words 
are typically slower to execute than the same computer programs or subroutines 
written in the form of native program instruction words due to the additional 
processing overiiead associated with interpretation. The different characteristics of 
IS computer programs or subroutines written in these two ways has the result that it is 
desirable to be able mix the two types of program words and rapidly and efficiently 
switch between them. 

When executing a portion of a computer program in the form of native 
program instruction words and it is desired to switch to executing interpreted program 
20 instruction words, then the instruction mteipreter must be invoked and passed the 
location of the interpreted program instruction words. It is often not possible or 
desirable to add a special purpose native program instruction word to carry out this 
task and so several nadve program instruction words have to be used to perform the 
switch. The use of several native program words to perform the switch is 
25 disadvantageously slow and uses extra memory capacity. 

Viewed from one aspect the invention provides apparatus for processing data 
under control of a computer program, said apparatus comprising: 

a processing unit responsive to native program instruction words to perform 
data processing operatioits; 
30 an instruction interpreter responsive to one or more inteifMreted instruction 

words specifying a data processing operation to execute native instruction words upon 
said processing unit to perform said data processing operation; and 
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a memory for storing said computer program; wherein 
said computer program includes both native instruction words and interprete i 
instruction words; 

a native code portion invokes interpretation of an interpreted code portion b r 
5 executing a native code call instruction to said instruction interpreter, 

execution of said native code call instruction triggers generation of a retiin 
address specifying a location within said memory for said native code call instruction 
and - 

said instruction interpreter uses said return address as a pointer to said interpretec 
10 code portion within said memory. 

Using a native code call instruction, as is normally provided in the instructioi 
set, to call/invoke the interpreter avoids the need for a special purpose native prograii 
instruction word to perform the switch. The location of the interpreted prograiii 
instruction words is passed to the interpreter in the return address of the native cod« 
15 call instruction and so only a single native code instruction is needed to make the 
switch. 

Whilst it is possible to do otherwise, it is preferred that said return address is 
an address immediately succeeding an address of said native code call instructiojti 
within said memory. 

20 As the return address points to the interpreted program instruction words, th^ 

these will normally be provided immediately following the native code call 
instruction. 

In order to manage the switch back to native code program instruction words, 
one preferred arrangement is that said instruction interpreter writes a new value of 
25 said return address for use by a native code return instruction as a pointer to a next 
native code instruction to be executed when interpretation of said interpreted code 
portion is finished and return is being made to execution of said next native code 
portion of said computer program. 

In accordance with the above, the return to native code execution may be 
30 made by an arrangement that said interpreted code portion finishes with an interpreted 
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return instruction that returns execution to a native code portion at an address pointed 
to by said return address. 

As an alternative, in some situations it may be preferred that said interpreted 
code portion finishes with an interpreted exit instruction that results in execution of a 
5 next native code portion stored within said memoiy at an address immediately 
following said exit instruction without a return being made corresponding to said 
native code call instruction. 

It is common for call return addresses to be stored in stack memory, however 
in preferred embodiments said processing unit includes a bank of data processing 
10 registers and said return address is stored within a predetermined data processing 
register vnthin said bank of data processing registers upon execution of said native 
code call instruction. 

Having the return address in a register allows use and manipulation of this 
address to take place without the overhead of having to recover the address from stack 
15 memory. 

Whilst having the return address available in a register for immediate use is an 
advantage, it is also sometimes desirable to release that register for other uses or to 
provide longer term storage of the return address. Accordingly, in preferred 
embodiments of the invention said memory includes a stack memory region and said 
20 return address is copied from said predeiemiined data processing register to said stack 
memory region upon invocation of said interpreted code portion. 

The interpreter can be made more simple, compact and fast in preferred 
embodiments in which each interpreted code instruction word corresponds to a native 
code instruction word. 

25 In practice the efficiency of the interpreter can be improved and the code 

density increased in preferred embodiments in which said native code instruction 
words form a native code instruction set and said interpreted code instruction words 
form an interpreted code instruction set, data processmg operations provided by said 
interpreted code instruction set being a subset of data processing operations provided 

30 by said native code instruction set. 

The interpretation simplicity and operationally efficiency are further improved 
in embodiments in v/tish said native code instruction words are X'bit uistruction 
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in response to one or more intezpieted instruction words specifying a data 
processing operation, executing with an instruction interpreter native instruction 
words upon said processing unit to perform said data processing operation; and 

storing said computer program in a memory; wherein 
5 said computer program includes at least one native code portion and at least 

one inteipreted code portion; 

a native code portion invokes interpretation of an interpreted code portion by 
executing a native code call instruction to said instruction interpreter; 

execution of said native code call instruction triggers generation of a return 
10 address specifying a location within said memory for said native code call instruction; 
and 

said instruction interpreter uses said return address as a pointer to said interpreted 
code portion within said memory. 

An embodiment of the invention will now be described, by way of example 
15 only, with reference to the accompanying drawings in which: 

Figure 1 is a schematic diagram of a data processing system; 

Figure 2 schematically illustrates switching fiom native code to interpreted 

code; 

Figure 3 illustrates a first mechanism for returning to native code execution 
20 &om inteipreted code execution; and 

Figure 4 illustrates an alternative way of invoking execution of interpreted 
code and a second mechanism for returning to native code execution firom interpreted 
code execution. 

Figure 1 illustrates a data processing system 2 comprising an integrated circuit 
25 4 coupled to a main memory 6. Within the integrated circuit 4 there is a processor 
core 8 and a cache memory 10. Within the processor core 8 there is an instruction 
decoding and control unit 1 1 coupled to a register bank 12. It will be appreciated that 
Figure 1 is a highly schematic representation of a data processing system that will in 
practice contain many more parts. 
30 The main memory 6 stores software programs and data to be processed. The 

processor core 8 fetches instmction words and data words from the main memory. 
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number of photon instruction words can be reserved for controlling the interpreter and 
other uses which do not have direct single equivalents in the native instruction words. 

Providing substantially each of the Photon instruction words in a one-to-one 
correspondence witii native instruction words simplifies the required interpreter such 
5 that this interpreter consumes relatively few resources and is able to operate rapidly 
and predictably. The interpreter may be a software interpreter or a hardware 
interpreter. Using the Photon instruction set, a hardware interpreter will have the 
advantage of requiring comparatively less storage space and a software interpreter 
will have the advantage of requiring comparatively fewer circuit elements. 

1 0 The sofhvare interpretw is "locked-down" within the cache memoiy 1 0. Thus, 

when the software inteiixeter is first invoked it will be loaded into the cache memory 
10 from the main memory 6 and thereafter remain within the cache memory 10 to be 
available for high speed use. Alternatively, the software interpreter may be pre- 
loaded into the cache memory 10 from the main memory 6 when the data processing 

IS system 2 is initialized. In either case, having a relatively small and efficient software 
interpreter that may be wholly stored within the cache memory 10 without consuming 
too great a proportion of the cache memory 10 is a strong performance advantage. 

The software interpreter itself is formed of native instruction words and serves 
to parse the inteipreted instruction words and map them to corresponding native 

20 instruction words. It will be apprcaated that whilst substantially each Photon 
instruction word corresponds to an ARM instruction, the software interpreter may 
need to execute a few ARM instructions to set up Ihe data in the correct registers and 
form prior to executing the ARM instruction that corresponds to the interpreted 
Photon instruction. 

25 In order that the system may operate effectively, it is important to have an 

efficient mechanism for switching between the execution of native instniction words 
and the execution of interpreted instruction words. The native instruction words 
instruction set is often abeady fixed and so it is not possible to add a special purpose 
switching instruction to the native instruction set. Furthermore, bit-space within a 

30 native instruction set is often a critical resource and so adding a switching institiction 
would reduce the amount of this resource available for other uses. 



Figure 2 illustrates a technique for switching between execution of natiV< 
instruction words and interpreted instruction words. The native instruction wor(i! 
include a subroutine call instruction that is normally used to jump to native cod( 
subroutines. When such a subroutine call is made, hardware mechanisms are alread) 
S in place that store a return address for the call such that native code execution can l^e 
resumed at the instruction following the siAroutine call once the subroutine hju 
completed. The interpreter invocation mechanism illustrated in Figure 2 uses a 
subroutine call 14 from the native code to the software interpreter code. The 
interpreted code 16 is stored in the memory locations inunediately following the 

10 subroutine call. Accordingly, the return address stored in response to the subroutine 
call 14 corresponds to the memory location of the start of the interpreted code 16. 
Accordingly, the software interpreter reads the return address and uses this as .a 
pointer to the interpreted code 16 which it is desired to execute. It will be seen fro](n 
Figure 2 that the native code comprises 32-bit native instruction words and the 

15 interpreted code comprises 8-bit interpreted instruction words, such that four 
interpreted instruction words can be stored in the same space that is required for la 
single native code instruction word. A single subroutine call instruction 14 is needed 
to perform the required switch to the start of execution of interpreted instructioin 
words. The subroutine call instruction 14 is already provided within the native code 

20 instruction set and so no additional bit-space within the native code instruction set js 
consumed. Furthermore, if the native code instruction set is one that is alreac^y 
established, then no modifications need to be made to the native code instruction s^t 
or hardware to utilize the interpreted code invocation technique illustrated in Figure 2. 
Figure 3 illustrates a first mechanism for returning to native code execution 

25 from interpreted code execution. A special purpose Exit instruction is provid^ 
within the interpreted code instruction set. Hie software interpreter is responsive to 
such an Exit instruction to simply cease interpretation of instruction words and instep 
pass control to the immediately following next native code instruction 18. Using this 
technique interpreted code can be freely mixed in with native code. 

30 Figure 4 illustrates an alternative technique for invoking the softwaile 

interpreter and a second mechanism for retuming to native code execution froiti 
interpreted code execution. Whilst Figure 3 allows interpreted code to be embeddejd 
within native code, it is not well suited to situations in which the interpreted code is 
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genuinely a subroutine that it is desired to invoke from several different points udthin 
the native code of the program as a whoh. Figure 4 illustrates a solution to this 
problem. A subroutine call 14 is issued to a subroutine Routine 1 in memory that 
appears to the overall native code program to be a native code subroutine in the 
S normal way. The subroutine Routinel stores the return address to the native code 
instruction 18 by pushing it to a stack memory area with native code instruction 20. 
The subroutine Routinel then makes a second subroutine call 22 to the start address 
of the interpreter software. This second subroutine call invokes interpreted code 
execution in the same way as illustrated in Figure 2 in that the retiim address from the 
10 subroutine call instruction 22 is used as a pointer to the start of the interpreted code 
16. 

At the end of the interpreted code there is a return instruction that is acted 
upon by the software interpreter to recover the return address from the subroutine call 
instruction 14 that was stored in the stack memory area. The software interpreter then 
IS passes control using this recovered return address to the native code instruction 18 
that is pointed to by the return address. 

In this way, the interpreted code can effectively be treated as a normal native 
code subroutine by the rest of the native code program. 

An alternative way of viewing the invention is set out as follows. 
20 Hiis describes a mechanism for invoking an inter[»eter to execute interpreted 

code. The mechanism uses a subrotitine call followed immediately by the code to be 
interpreted. The interpreter uses the return address of the subroutine as the starting 
address of the code to be interpreted. If the interpreter needs to return from 
interpreting code it adjusts the return address to point to the end of the interpreted 
25 code so that on return from the inteipreter. normal (native) program execution will 
continue at the instruction after the inteipreted code. 

Alternatively, if the interpreter needs to perform a return directly to the caller 
of the original function containing the interpreted code, it can pop the return franje 
from the stack. Execution will then continue at the instruction after the call to the 
3 0 function containing the interpreted code. 

A code exanq>le of the mechanism illustrated in Figure 2 using the ARM 
processor with the Photon interpreter is as follows: 



10 



CODE32 ; Instruct the assembler that what follows is 

ARM code. 

BL Execute_Photon ;Call the Photon interpreter 

5 PHOTON ;Instruct the assembler that what follows is a 

Photon byte code 

<Photon byte code inserted here> 



In the above code example the processor executes the first instruction (BL) as 
10 a native ARM instruction. The BL instruction (a subroutine call in ARM) invokes i&t 
interpreter which then executes then native ARM instructions necessary to interpret 
the bytes following the BL instruction as Photon byte code. 

Benefits 

Previously to invoke the interpret on a section of interpreted code the 
IS processor would have to load the address of the code to be executed into a register 
(say RO) and then call the interpreter. e.g. 



ADR rO. Interpreted_code 

BL Execute_Photon 



Inteipreted_Code 

■interpreted code heie> 



25 With the "Interpreter Invocation Mechanism'* the code to be interpreted can bp 

placed immediately after the call to Execute_Photon. There is then no need to load 
RO with the address of the code to be interpreted. This has the following benefits. 
• There is a saving of one instruction per interpreter invocation 
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II 

• There is no need to reserve a register to hold the address of the code to be 
interpreted. As the point of a subroutine call is often the point where the 
register pressure is greatest there may not normally be a free register 
available to use to point to the interpreted code. For example, in the above 
5 RO is typically used to hold tbe 1*' argument to the function. 

A code exanq)le of the mechanism illustrated in Figure 3 using the ARM 
processor with the Photon inteipreter is as follows: 

;Instruct the assembler that what follows 
is ARM code 
;Call the Photon intetpreter 
;Instruct the assembler that what follows is a 
Photon byte code 

;Photon Exit interpreter instruction 
;Instiuct the assembler that what follows is 
ARMcode 



CODE32 

10 

BL Execute_Photon 
PHOTON 

<Photon byte code inserted here> 

15 EXIT 
CODE32 



As in the first example the processor executes the first 2 instructions as native 
20 ARM code and then invokes the interpreter to execute Photon code immediately 
following the BL. 

Execution of Photon code by the interpreter continues until ibe interpreter 
encoimters a Photon 'EXIT* instruction. The interpreter then takes its IP register 
(Interpreter Pointer) and uses this to return to the ARM instructions immediately 
25 following the Photon code. 

Benefits 

The use of an EXIT instruction within the interpreter allows the interpreter to 
return directly to the code after the interpreted code. This allows interpreted code to 
be intermingled with native code. The possible benefits of this are. 
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• A compiler can choose to compile sections of C (or other high ieVe 
language code) to either native machine code, or interpreted co0 
depending on which is more efficient in temts of code size or perfoimande 
In a further example a subroutine call is made to a 1** routine which is part b " 
5 its entry sequence performs a subroutine call to invoke the interpreter. The interprelie 
then executes interpreted instructions m the l" routine until it encoimters ^ii 
interpreted RETURN instruction. Rather than continuing execution after th< 
RETURN instruction as in the example of the EXIT instruction above it insteac 
returns immediately to the caller of the 1*' routine. 

10 A code exan4>le of the mechanism illustrated in Figure 4 using the ARN/ 

processor vwth the Photon interpreter is as follows: 



CODE32 

IS <ARMccde> 

BL Routmel 
<ARMcode> 



;histruct the assembler that what follows 
is ARM code 

;Ordinary call to Routine! 

;Execution continues here after execution of 

Routine 1 



STMDB sp!, {sp, Ir} 



BL 

25 PHOTON 



;Instruct the assembler that vAxat follows is 
ARM code 

;Save return address for this fimction and also 
save stack pointer to allow for stack unwinding, 
Execute_Photon ;Call the Photon interpreter 

;In$truct the assembler that what follows is a 
Photon byte code 



<Photon byte code mserted here> 
RETURN 



;Photon RETURN interpreter instruction 



In this example an initial subroutine call is made to Routinel . Routinel then 
perfonns an entry sequence which consists of a STMDB instruction which saves the 
link register (LR) and the stack pointer (SP). The link register contains the return 
address for the Routine. 

Execution of a Photon code by the interpreter continues until the interpreter 
encounters a Photon RETURN instruction. The interpreter then pops the link register 
and stack pointer fh>m the stack and moves the link register into the program counter 
(PC) by performing the following sequence 

LDMIA sp, {sp, Ir} 
BX Ir 

This has the effect of letuming to the instruction inunediately following the 
original subroutine call to Routinel. 

Benefits 

The use of the Interpreter Invocation Mechanism in the entry sequence of a 
function combmed with the RETURN interpreted instruction allows a function to be 
written in interpreted code but be transparently viewed from the rest of the system as 
though it were written in native code. This has the following benefits. 

• A compiler can choose to compile entire functions in either native code or 
interpreted code depending on what is most efficient in terms of code 
density or performance without needing to know whether the target 
function is interpreted code or native code. Since, for languages such as C 
different functions may be compiled from separate source files at different 
times the compiler can not know whether the target function is interpreted 
code or native code 

• As software is usually developed in a modular fashion with different 
developers working on different sections of code it eases the task of 
software development as individual software developers can choose to 
write code in either interpreted code or native code and know that software 
written by other developers can call their software regardless. 
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Further Benefits 

The above examples show the benefits as applied to ARM and Photon. These 
benefits also apply to other architectures and other interpreted languages. 

For example the benefits of the above would also apply to the Inte 
S 80x86/Pentium architectures with Java as the interpreted language. 

This would allow Java and C code to be intermixed freely. For example 
following a C Entry Point an Entry sequence could be executed followed by a call toja 
■ Java interpreter. A Java return instruction would return control to the instructipr 
following the Java code. 
10 Alternatively one could use the same idea with one of the 80x86/Pentiu|i] 

architectures with a BASIC languages such as Visual BASIC as the interpreted 
language. 
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CLAIMS 

1. Apparatus for processing data under control of a computer program, said 
apparatus comprising: 

5 a processing unit responsive to native program instruction words to peifonn 

data processing operations; 

an instruction interpreter responsive to one or more interpreted instruction 
words specifying a data processing operation to execute native instruction words upon 
said processing unit to perform said data processing operation; and 
10 a memory for storing said computer program; wherein 

said computer program includes both native instruction words and interpreted 
instruction words; 

a native code portion invokes interpretation of an interpreted code portion by 
executing a native code call instruction to said instruction inteipreter; 
IS execution of said native code call instruction triggers generation of a return 

address speciiying a location vyithin said memory for said native code call instruction; 
and 

said instruction inteipreter uses said return address as a pointer to said 
interpreted code portion within said memory. 

20 

2. Apparatus as claimed in claim I, wherein said return address is an address 
immediately succeeding an address of said native code call instruction within said 
memory. 

25 3. Apparatus as claimed in any one of claims 1 and 2, wherein said instruction 
interpreter writes a new value of said return address for use by a native code return 
instruction as a pointer to a next native code instruction to be executed when 
interpretation of said interpreted code portion is finished and return is being made to 
execution of said next native code portion of said computer program. 

30 
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4. Apparatus as claimed in claim 3, wherein said inteipreted code portioi 
finishes with an interpreted retvim instruction that returns execution to a native cod< 
portion at an address pointed to by said return address. 

5 5. Apparatus as claimed in any one of claims 1 and 2, wherein said interpret^c 
code portion finishes with an interpreted exit instruction that results in execution oti 
next native code portion stored within said memory at an address immediatejj 
.following said exit instruction without a return being made corresponding to sale 
native code call instruction. 

10 

6. Apparatus as claimed in any one of the preceding claims, wherein sale 
processing unit includes a bank of data processing registers and said return address 'u 
stored within a predetermined data processing register within said bank of data 
processing registers upon execution of said native code call instruction. 

15 

7. Apparatus as claimed in claim 6, wherein said memory includes a stack 
memory region and said return address is copied from said predetermined data 
processing register to said stack memory region upon invocation of said interpreted 
code portioiL 

20 

8. Apparatus as claimed in any one of the preceding claims, wherein 
substantially each interpreted code instruction word corresponds to a native code 
instruction word. 

25 9. Apparatus as clauned in claim 8, wherein said native code instruction words 
form a native code instruction set and said interpreted code instruction words form an 
interpreted code instruction set, data processing operations provided by said 
interpreted code instruction set being a subset of data processing operations provided 
by said native code instruction set. 
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10. Apparatus as claimed in any one of the preceding claims, wherein said native 
code instruction words are X-bit instruction words and said interpreted code 
instruction words are Y-bit instruction words, X being greater than Y. 

5 11. Apparatus as claimed in any one of the preceding claims, wherein said native 
code instruction words specify N-bit data processing operations to be performed by 
said processing unit and said interpreted code instmction words specify N-bit data 
processing operations to be performed by said processing unit. 

10 12. Apparatus as claimed in claims 10 and 1 1, wherein X is equal to R 

13. Apparatus as claimed in claim 12, wherein Y is N/4. 

14. Apparatus as claimed in any one of Ae preceding claims, wherein said 
15 instruction interpreter is a software interpreter provided by an interpreter computer 

program fonned of native code instruction words executed by said processing unit. 

15. Apparatus as claimed in claim 14, comprising a cache memory and wherein 
said software interpreter is, in use, stored within said cache memory. 

20 

16. Apparatus as claimed in claim IS, wherein said software interpreter is stored 
within said cache monory both when executing native program instruction words and 
interpreted program instruction words. 

25 17. Apparatus as claimed in any one of the preceding claims, wherein portions of 
said computer program having less than a threshold required execution speed are 
provided as interpreted code instructions words and portions of said computer 
program having greater than said threshold required execution speed are provided as 
native code instructions words! 

30 
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18. Apparatus as claimed in any one of the preceding claims, wherein portions of 
said computer program having less than a threshold execution frequency are provid^ 
as interpreted code instructions words and portions of said computer program having 
greater than said threshold execution frequency are provided as native code 

S instructions words. 

19. A method of processing data under control of a computer program, said 
method comprising the steps of: 

in response to native program instruction words, performing data processing 
1 0 operations with a processing unit; 

in response to one or more interpreted instruction words specifying a data 
processing operation, executing with an instruction interpreter native instruction 
words upon said processing unit to perform said data processing operation; and 
storing said computer program in a memory; wherein 
IS said computer program includes at least one native code portion and at least 

one interpreted code portion; 

a native code portion invokes interpretation of an interpreted code portion by 
executing a native code call instruction to said instruction interpreter; 

execution of said native code call instruction triggers generation of a returb 
20 address specifying a location within said memory for said native code call instruction; 
and 

said instmction interpreter uses said return address as a pointer to said 
interpreted code portion within said memory. 

2S 20. Apparatus for processing data substantially as hereinbefore described with 
reference to the accompanying drawings. 



21. A method of processing data substantially as hereinbefore described with 
reference to the accompanying drawings. 



V^UR^ * INVESTOR IN PEOFIE 

R 

Application No: GB 0001030.6 ' Examiner: Mike Davis 

Claims seardied: 1-21 Date of search: 24 August 2000 



Patents Act 1977 

Search Report under Section 17 




Databases seardied; 




UK Patent OflFice collections, including GB, EP, WO & US patent specifi 


»tians, in: 


UKCl(Ed.R): G4A(APB) 




IntCl(Ed,7): G06F 




Other: Online: WPI, EPODOC, JAPIO 





Documents considered to be relevant: 



Category 


Identic of document and relevant passage 


Relevant 
to claims 




None 





X DoeunuBliailieMiBsbck of novelty or mventiveitcp A Pocmnent inrtiraitiiig technotogiial hackgromd »nil/or state of ihe m. 
Y Doemntat iadiMtmg Uck of iavwtive itq> if combined P Ooeuinent|wbUi]iedoDor»flcrtbedeclaiedpri(>ritydatsbutbeforethe 
'witboDeormanoilMriiocniMnttQf HuneMtegaiy. filing dtia of ibiti&vaatioa. 

B Peleat docinncat poblidied on or Ifier, but with priority cUie earlier 
Jt Meabwcfthenmopitentftiinly thin, the filing date of thfa i{>plic>iion. 



An Executive AgoKy of the Department ofTradc and Industry 

BNSOCMD! <GB___a35a2etA_U> 



